The CropPad was a bit of a red herring. That transform is very special. It is not used as an augmentation, rather it is the function with which we go from input data of arbitrary shape and dimensions to the required dimensions.
It is used for either:

1. if the data is a 3D image, but we are training a 2D model, then we will load a 3D volume and select 1 slice of the x dimension to end up with a 2D image.
2. If the data is a 3D image of shape (241, 632, 421) but our patch size is only (128, 128 128) then we will crop it down to the patch size, before we apply all our augmentations, to not waste a lot of computations.
   So, CropPad needs to support a lot of cases that e.g. Blur does not need to.

Therefore for Blur you can assume that data will be either 3D (H,W,D) or 2D and should stay in those dimensions.

I will prepare a draft for how to package it and add that to your PR if that's fine? :)

I'm a bit afraid of the "deform_coordinate_matrix" in torch_spatial. Can be a rather expensive operation and that one is still np/cpu

Edit: yes so I just tried this. The spatial func runs in 14 secs when using "deform_coordinate_matrix" and 1 sec when not using it, so that part definitely hurts

Modified the spatial impl. Trying with 3 separable 1D gauss convs as approximating kernels. Kernel sizes are fixed (suggest: hyper search good general size). Visually I don't see a difference, I haven't done thorough performance measures.

ALSO: Looked at Kornia's impl. Couldn't find a 3D gaussian fn @Sllambias ?? Do u have a good bench to test if there's "mere knald på nu"? xD